feat(reports): render print preview from the same document as the PDF - #60
Merged
Conversation
The print tab re-implemented the report layout in JSX with its own @media print stylesheet, while the PDF export rendered a Blade template through Dompdf. Two independent implementations of the same document, so they disagreed on markup, on styling, and on content: the preview showed only the current preview page while the export contained every record. Extract renderReportHtml() as the single rendering, used by the PDF export and by a new POST /reports/preview/html. The print tab now embeds that document in an iframe and prints the iframe, so what is previewed is what is printed and what is exported. This removes ~156 lines of duplicated JSX and the 81-line print stylesheet. Also raise the export limits, measured against the real dev report: card rendering of 247 records peaks at 288M, which the 256M limit killed outright, and takes long enough to need a higher max_execution_time and a matching nginx fastcgi_read_timeout.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes defect (f) from manual QA, and lifts the export memory ceiling.
The problem
The print tab re-implemented the report layout in JSX with its own
@media printstylesheet, while the PDF export rendered a Blade template through Dompdf. Two independent implementations of the same document, so they disagreed on markup, on styling, and — least obviously — on content: the preview renderedpreviewData, which is paginated, while the export ran unpaginated. Printing gave you one page of records; exporting gave you all of them.The change
renderReportHtml()is now the single rendering of a report document. The PDF export and a newPOST /reports/preview/htmlboth go through it. The print tab embeds that document in an iframe and prints the iframe, so what is previewed is what is printed is what is exported — by construction, not by keeping two implementations in step.This removes ~156 lines of duplicated JSX and the 81-line print stylesheet.
Export limits
Raised, with numbers measured against the real dev report rather than picked round:
memory_limitmax_execution_timefastcgi_read_timeoutAll three were needed: raising memory alone still left the request dying on a timeout.
Verification
Driven against the running stack:
Also: 185 API tests (2 new — the preview HTML is unpaginated, and it honours the selected card view), 76 client tests (3 new — the iframe carries the API document, print targets the iframe rather than the page, and a failed load reports instead of showing a blank frame), Pint,
tsc -b, ESLint, Prettier.Still open — needs your call
Card mode remains heavy at scale: 248 pages for 247 records, roughly one card per page. That is content, not CSS — the view stacks 16 fields with 12 in a single column and titles that wrap to three lines. I measured removing the column
min-height, tightening field margins and card padding, and shrinking the@pagemargins; none crossed the threshold to two cards per page, so I shipped none of them. Options worth deciding on: cap records per export, offer landscape, or trim the fields in the card view.